Skip to content

Name the leg that reads the shell, in the audit that says nothing does - #173

Merged
iderex merged 1 commit into
mainfrom
ci/the-audit-names-what-reads-the-shell
Aug 22, 2026
Merged

Name the leg that reads the shell, in the audit that says nothing does#173
iderex merged 1 commit into
mainfrom
ci/the-audit-names-what-reads-the-shell

Conversation

@iderex

@iderex iderex commented Aug 22, 2026

Copy link
Copy Markdown
Contributor

The issue this belongs to

Closes #172.

What changed

The header of .github/workflows/zizmor.yml stops counting the tracked shell
scripts and stops saying that no analyser for their language is configured here.
It names .github/workflows/shell-analysis.yml as the leg that reads them, says
why that is a separate leg rather than a setting inside this one, and says which
halves of #81 are still open so the pointer does not read as closed either.

The count is removed rather than corrected. The next script to land would break a
corrected number in exactly the same way, and a header comment cannot carry the
command that would derive it.

The means is prose in the file that carries the claim. What is wrong is what a
comment asserts, and no check in this tree reads a claim in a workflow comment, so
there was nothing else available.

What failure it prevents

Somebody opening the workflow that audits the workflows, to find out what the gate
does and does not read, is told that the shell in this repository is unanalysed.
They close the file wrong about the gate they were checking, and the sentence
misleads precisely the reader who came to it for coverage.

Evidence

The two sentences, at the commit this branch is cut from:

git grep -n 'Two tracked shell scripts\|no analyser' origin/main -- .github/workflows/zizmor.yml
origin/main:.github/workflows/zizmor.yml:6:# rest. Two tracked shell scripts carry the rules of the document check and the
origin/main:.github/workflows/zizmor.yml:7:# hygiene check, a workflow runs each of them on a pull request, and no analyser

Three scripts rather than two:

git ls-tree -r --name-only origin/main | grep -E '\.sh$'
.github/doc-paths/doc-paths.sh
.github/pr-hygiene/hygiene.sh
.github/shell-analysis/shell-analysis.sh

An analyser for their language is configured, and it ran on the head of the
default branch:

git grep -ln 'shellcheck' origin/main -- .github/workflows/
origin/main:.github/workflows/shell-analysis.yml
gh api repos/Flowfin/core/commits/main/check-runs --jq '.check_runs[] | select(.name | startswith("Analyse the shell")) | "\(.name)\t\(.conclusion)"'
Analyse the shell the gate runs (shellcheck)	success

The condition in #172 is that both of these answer with nothing. On this branch:

git grep -c 'Two tracked shell scripts' -- .github/workflows/zizmor.yml ; echo "exit=$?"
exit=1
git grep -c 'no analyser' -- .github/workflows/zizmor.yml ; echo "exit=$?"
exit=1

What a guard here refuses, and the proof it bites

No guard is added, and none exists for this class. The check for a named path that
does not resolve reads markdown only, so prose inside a workflow file is outside
what it looks at:

sed -n '439,441p' .github/doc-paths/doc-paths.sh
documents() {
  git ls-files '*.md'
}

Nothing refused the sentence that went wrong and nothing would refuse the next
one. Removing the count rather than correcting it is the whole of the mitigation.

What this does not cover

NOT COVERED: the rest of that header. The persona argument, the severity setting
and the rule for future workflow changes are untouched.

NOT COVERED: the same shape anywhere else. This change reads one file. A claim
written into another workflow comment is unaffected, and nothing here searches for
one.

NOT ADDED: no mechanism. #172 asks for the sentences to be true, not for a check
that would refuse the next false one.

NOT CLOSED: #81. The header now says which of its halves are still open, and this
change moves neither of them.

Who has read it

Nobody but me. There is no second reader on this board tonight, and the commands
above and the checks on this pull request stand in place of one rather than the
question being left open.

The header of the workflow audit tells a reader what that audit does not
reach. It counted the tracked shell scripts and said no analyser for
their language is configured anywhere in this tree. A check that reads
exactly that language landed on main and this header did not move with
it, so somebody opening the workflow that audits the workflows read that
the shell here is unanalysed and closed the file wrong about the gate
they were checking.

The count is gone rather than corrected, because the next script to land
would break it again. The sentence about the absence names the workflow
that ended it, and what of that issue is still open is stated so the
pointer does not read as closed either.

Closes #172

Signed-off-by: Nils Lehnen <30603423+iderex@users.noreply.github.com>
@iderex iderex added ci documentation Improvements or additions to documentation labels Aug 22, 2026
@iderex iderex self-assigned this Aug 22, 2026
@iderex
iderex merged commit 7a8b187 into main Aug 22, 2026
10 checks passed
@iderex
iderex deleted the ci/the-audit-names-what-reads-the-shell branch August 22, 2026 05:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

ci documentation Improvements or additions to documentation

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Add code scanning over this repository's own language The workflow audit says the shell here is unanalysed, and a check that reads it landed

1 participant